Fix native app windows restoring the wrong saved instance - #763

@claude does this interfere with the mobile experience of unifying the desktops? adds any regression?

Claude finished @AllTerrainDeveloper's task in 2m 15s —— View job

Answering: mobile impact of this PR

• Read trigger comment and PR context
• Review mobile-related changes in this PR (src/mobile/constraints.ts, mobile-recents restore path)
• Check for interaction with "unifying desktops" mobile feature
• Check test coverage for regressions
• Post findings

Short answer: no, this doesn't interfere with the phone "one desk" behavior, and it looks like a net improvement for mobile rather than a regression.

Why

"Unifying the desktops" on mobile is the behavior documented in docs/mobile.md and src/mobile/constraints.ts:16-24: while the mode is mobile, every window (from session restore or a tapped recent) is folded onto the single active desk, and folded back to its original desk on the crossing back to desktop. That logic is driven entirely by two generic window-manager hooks:

• HOOKS.WINDOW_GEOMETRY filter — forces state: 'maximized' on open/restore.
• HOOKS.WINDOW_OPENED action — triggers foldIfNeeded() / maximizeIfNeeded().

This PR's restore-path change (src/boot/session.ts, src/native-windows.ts, src/desktop.ts) swaps native-window session restore from manager.open() + seedWindowRestoreState() to manager.openNew() with the saved state (desktopId, geometry, params, etc.) passed directly. WindowManager.openNew() fires the exact same WINDOW_GEOMETRY filter and WINDOW_OPENED action/CustomEvent that open() does (src/window-manager/index.ts:1095 and :1452), so foldIfNeeded()/maximizeIfNeeded() still run unchanged. desktopId still lands on win.config.desktopId, which is exactly what foldIfNeeded() reads (constraints.ts:155). So the phone's "one desk" folding and full-screen forcing are unaffected by which manager method restore uses.

Mobile recents are actually part of the fix, not just untouched

src/mobile/constraints.ts's recents.open() for native windows previously used the old, buggy pattern this PR is fixing: manager.seedWindowRestoreState() + openNative(id). It's now updated to call the new openNative(id, baseId, state) signature directly (see the diff in mobile-constraints.ts and the updated tests/vitest/mobile-constraints.test.ts), so reopening a duplicate native instance (e.g. a second Fleet site) from the phone's recents/switcher gets the same identity-safe restore as desktop session restore. That's the "Uses the same identity-safe restore path for mobile recents" line in the PR description — it extends the fix to mobile, it doesn't just leave mobile alone.

One nuance worth knowing (not a bug)

A phone boot only restores the single focused session window (trimSessionForMobile()/splitSessionForMobile() park the rest as recents before restoreSession() even runs), so the "restore N duplicate native instances at once" scenario this PR targets mostly matters in desktop mode. On mobile it matters one window at a time, via recents.open(), which is exactly the path that got updated.

Caveats

• I verified this via static reading of the diff and hook wiring (git diff origin/trunk...HEAD), tracing openNew() vs open(), and the mobile constraints module's hook subscriptions. I did not have shell permissions in this run to execute npm run test:js / npx vitest, so I couldn't independently re-run the mobile or session-restore-duplicates suites — the PR description already reports the full 5,849-test suite and a focused 90-test restore/mobile/registry suite passing, and the diffs to tests/vitest/mobile-constraints.test.ts line up with the new OpenNativeWindow signature.
• No dedicated test combines "mobile mode + duplicate native instance restore + desk crossing" in one scenario, but that gap predates this PR and isn't introduced by it.